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Abstract-  The  purpose  of  the  this  report  is  to  assist  the  Navy  Management 
Systems  Support  Office  in  performing  software  maintenance  by  showing  a 
detailed  example  of  applying  the  software  change  management  methodology  which 
was  described  in  the  previous  report:  ‘Software  Maintenance:  The  Need  for 
Standardization',  Norman  F.  Schnei dewind ,  February  1989,  Naval  Postgraduate 
School  Technical  Report  NPS-54-a9-02.  The  maintenance  of  local  area  network 
software  is  used  as  the  example. 


I.  INTRODUCTION 

Software  maintenance  is  a  major  activity  at  the  Navy  Management  Systems 
Support  Office  (NAVMASSO) .  The  purpose  of  the  this  report  is  to  assist  the 
Navy  Management  Systems  Support  Office  in  performing  software  maintenance  by 
showing  a  detailed  example  of  applying  the  software  change  management 
methodology  which  was  described  in  the  previous  report:  ‘Software  Maintenance: 
The  Need  for  Standardization',  Norman  F.  Schnei dewi nd ,  February  1989,  Naval 
Postgraduate  School  Technical  Report  NPS— 54-89-02 .  The  maintenance  of  local 
Area  network  software  is  used  as  the  example.  The  methodologv  is  general  and 
can  be  applied  to  any  programming  environment  and  language,  including  COBOL. 

As  an  introduction  to  the  subject  of  software  maintenance,  we  provide  some 
definitions  followed  bv  an  explanation  of  the  importance  of  the  eubiect. 

A.  Definitions  ' 

Software  Maintenance:  Modification  of  a  software  product  after  delivery 

to  correct  faults,  to  improve  performance  or 
other  attributes,  or  to  adapt  the  product  to  a 
changed  environment  -CIJ. 

This  definition  is  the  conventional  one  and  is  useful  if  our  interest  in 
modification  to  software  is  limited  to  changes  that  are  made  after  the 
software  is  delivered.  However,  it  is  a  fact  that  changes  are  not  confined  to 
the  post-del i very  phase;  they  are  made  during  all  life  cycle  phases.  In  some 
cases,  changes  are  made  in  significant  numbers  prior  to  delivery. 


Maintainability;  The  ease  with  which  a  software  can  be  maintained 


Change  Managements 


The  process  of  making  changes  to 
controlling  their  effects  during  the 
the  software. 


software  and 
entire  life  of 


to  software 


The  last  definition  recognizes  the  fact  that  modifications 
be  managed  effectively  during  the  entire  life  of  the  software.  It  i 
definition  used  here. 


must 

the 


t 


I 


Pages 

According  to  various  sources,  software  maintenance  accounts  for  a 
significant  amount  of  the  total  time  and  cost  of  running  a  data  processing 
organization.  For  example,  one  study  reports  the  following:  about  half  of 
applications  staff  time  spent  on  maintenance,  over  40  percent  of  the  effort  in 
supporting  an  operational  application  system  spent  on  user  enhancements  and 
extensions,  and  about  half  a  man-year  of  effort  allocated  annually  to  maintain 
the  average  system  {2> .  In  another  report  the  same  authors  list  the  factors 
which  cause  the  significant  maintenance  effort;  system  age,  system  size, 
relative  amount  of  routine  debugging,  and  the  relative  development  experience 
of  the  maintainers  t3> .  System  age  drives  the  other  factors;  with  increased 
system  age,  system  size  increases,  leading  to  greater  effort  allocated  to 
routine  debugging,  and  with  increased  system  age,  the  relative  development 
experience  of  the  maintainers  declines  due  to  organizational  turnover  and 
change.  All  of  these  factors  tend  to  increase  the  time  and  cost  of  performing 
maintenance.  Thus  maintenance  is  an  area  that  deserves  a  lot  of  attention. 
Improvements  in  maintenance  practices  should  result  in  reduced  costs  and 
increased  effectiveness  of  performing  maintenance. 

However  there  is  a  limit  to  reducing  cost  and  increasing  effectiveness 
through  improved  practices,  because  the  maintainability  of  the  software  has 
largely  been  determined  by  the  developer  before  it  ever  reaches  the 
maintainer.  The  maintainer  can  only  influence  quality  during  the  maintenance 
phase  of  the  software  life  cycle.  The  quality  of  the  software  as  designed  is 
determined,  in  part,  by  whether  the  software  development  methodology  assists 
the  developer  in  producing  maintainable  software.  Consequently,  maintenance 
practices,  which  maintainers  control,  and  development  methodology,  which 
developers  control ,  are  candidates  for  standardi zati on  {4>.  Significant 
efforts  have  been  made  at  the  National  Institute  for  Standards  and  Technology 
(formerly  the  National  Bureau  of  Standards)  to  promote  standardized 
maintenance  practices  through  the  publication  of  a  series  of  guides  on 
software  maintenance  and  software  maintenance  management <51 . 

The  objective  of  standardization  is  to  improve  the  maintainability  of  both 
existing  and  new  software.  However,  we  should  recognize  the  limitations  of 
using  standardi sat  1  on  to  solve  the  'maintenance  problem'.  These  are  the 
following:  Much  of  the  software  that  is  maintained  was  developed  without 
benefit  of  any  methodology;  consequently,  methodology  is  of  limited  use  in 
these  cases.  2)  Conversely,  methodology  is  most  useful  when  applied  to  new 
software.  3)  Related  to  paints  1  and  2  is  the  fact  that  improvements  in 
maintenance  practices  are  only  applicable  to  existing  software.  4)  An 
important  determinant  of  the  maintainability  of  software  is  the  knowledge  and 
skill  of  the  developer  and  maintainer.  5)  There  are  other  aspects  of  a 
development  methodology,  such  as  expressiveness,  that  are  important  when 
evaluating  it  as  a  development  tool  in  addition  to  its  usefulness  as  an  aid 
for  producing  maintainable  software.  Points  4  and  5  are  beyond  the  scope  of 
the  paper  as  are  the  areas  of  software  engineering  environments  and  tools, 
which  can  contribute  significantly  to  the  quality  of  both  development  and 
mai ntenance. 
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The  paper  consists  o-f  the  -following  sections; 

I I .  Purpose 

III.  Local  Area  Network  Example 

IV.  Objective  of  Maintenance 

V.  Metrics  for  Maintenance 

VI.  Model  of  Maintenance 

VII.  Application  of  Metrics 

VIII.  Standardization  of  Change  Documentation 

IX.  Software  Communication  Mechanisms  and  Maintenance 

X.  Standardization  through  Examination  of  Development  Methodologies 

XI.  Summary 

Each  onnciple  of  the  change  management  methodology  is  illustrated  by  the 
aopropriate  part  of  a  local  area  network  (LAN)  software  maintenance  example  so 
that  the  reader  can  immediately  see  an  application.  The  same  example  is  used 
throughout  the  paper  to  maintain  continuity  for  the  reader.  This  example  is 
used  to  illustrate  how  mistakes  can  be  made  if  maintenance  is  performed 
without  using  a  formal  change  orocedure.  The  example  is  also  used  to  show  how 
mistakes  can  be  avoided  by  applying  the  change  management  methodology. 
Following  the  statement  of  each  change  methodology  principle  is  an  example 
drawn  from  the  LAN  application.  The  examples  are  delineated  by  the  use  of 
vertical  bars  <  1  ). 

! I .  PURPOSE 

The  first  purpose  of  the  paper  is  to  present  the  case  for  standardizing 
software  maintenance  practices  and  those  aspects  of  software  development 
methodology  that  affect  the  maintainability  of  the  delivered  software.  The 
second  purpose  is  to  show  how  to  apply  the  change  management  methodology. 
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III.  LOCAL  AREA  NETWORK  EXAMPLE 

Since  the  example  will  be  used  throughout  the  paper,  it  is  necessary  to 
present  an  overview  o-f  the  LAN  so-ftware  maintenance  application  at  this  point. 
A  discussion  of  all  aspects  o-f  the  changes  which  were  made  to  the  LAN  software 
in  the  example  is  beyond  the  scope  of  this  report. 

Figure  1  shows  Servers  and  User  Computers  on  a  Token-Ring  LAN  with  the 
pertinent  batch  programs  keyed  to  the  diagram.  Briefly,  the  functions  of  these 
programs  are  the  following: 

Server 


Autoex ec . Bat :  Start  the  Server  on  network  and  share  resources. 

Profile. Rat:  Process  User  Computer  identifications  to  identifv 

c onf  1  qur at  1  on  <e.g.,  modem,  EGA  card,  3270  EmLilation. 
etc .  )  . 

Set  conf 1 gur at  1  on  in  memory  (the  environment'. 

Application:  Check  configuration.  Execute  application  program  if 

Batch  Files  required  hardware  available.  Otherwise,  display  error 
message. 

User  Computer 


Autoexec.bat:  Set  User  Computer  i dent i f i cat i on  in  the  environment. 

User.  Bat  ;  Display  logon  instructions  to  the  'wiser. 

Start. Bat  ;  Start  User  Computer  on  network,  request  resources  from 
Server  and  call  Profile. Bat. 
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Figure  1.  Token-Ring  Network  Diagram 
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A  batch  (command  -file)  -for  starting  a  user  personal  computer  on  a  local 
area  network  (LAN)  and  requesting  resources  provided  by  a  server  is  shown  in 
Figure  2  (Start. Bat)  and  the  corresponding  state  diagram  is  shown  in  Figure  3. 
This  batch  -file  was  modi-fied  to  provide  some  additional  network  capabilities 
as  shown  in  Figure  2;  the  corresponding  modification  is  shown  in  Figure  3  wi-th 
dotted  boxes.  The  boxes  represent  states  and  the  arrows  represent  state 
transi tions. 

The  enhancement  provides  the  ability  to  store  the  User  Computer 
con-figuration  (e.g.,  presence  o-f  a  modem)  in  memory  and  to  check  the 
con-figuration  prior  to  executing  an  application  which  requires  a  given  device. 
The  purpose  is  to  prevent  the  user  from  wasting  time  if  the  required  device  is 
not  available,  and  to  notify  the  user  of  this  situation  with  a  message  that 
identifies  computers  that  have  the  required  device.  In  addition,  a  significant 
reduction  in  software  maintenance  is  achieved  by  having  onlv  one  set  of 
application  batch  files  to  maintain  rather  than  various  sets,  with  each  set 
tailored  to  a  different  configuration.  Lastly,  this  approach  achieves  a 
uniform  user  application  program  interface. 

The  numbers  on  the  left  side  of  the  commands  in  the  batch  file  correspond 
to  the  numbers  on  the  state  boxes  on  Figure  3.  The  convention  for  labeling 
state  transition  arrows  is:  Event /Acti on .  In  some  cases  in  Figure  3  there  is 
no  event;  in  these  cases  ' NE '  is  used  to  indicate  this.  The  DOS  and  PC  LAN 
Program  handle  transfers  of  control  implicitly  (e.g.,  a  transfer  of  control 
occurs  automatical ly  from  PC  LAN  Program  to  DOS  under  certain  error 
conditions).  There  is  no  capability  in  the  batch  file  language  for  describing 
error  conditions  explicitly,  although  they  are  shown  in  the  state  diagram  to 
clarify  the  operation. 

Asterisks  in  the  batch  file  identify  comments.  Unfortunately,  the  comment 
concerning  accessing  the  D  drive  was  not  changed  with  the  modification.  This 
comment  is  no  longer  applicable  and  caused  confusion  in  trying  to  understand 
the  program  logic.  With  the  modification,  neither  the  D  drive  nor  the 
directory  program  IDIR  are  accessed  at  this  point  in  the  program.  The  comment 
should  have  been  changed  to  refer  to  the  E  drive  and  the  PROFILE  program.  This 
affects  the  transitions  from  states  5  to  6  and  6  to  7.  For  the  sake  of 
brevity,  the  error  events  and  actions  associated  with  states  6’  and  7'  are  not 
shown  in  Figure  3;  they  are  similar  to  those  for  states  6  and  7. 

Neither  a  state  diagram  nor  another  type  of  methodology  that  would  show  the 
consequences  of  making  a  change  was  used  in  creating  the  batch  program.  The 
use  of  such  a  methodology  would  have  helped  to  avoid  this  kind  of  error  by: 

o  Preventing  side  effects  (erroneous  comment) 

o  Providing  ability  to  make  selective  change  (replace  commands  6  and  7  with 
6'  and  7'  correctly). 

n  Identifying  existing  communication  linkages  (communication  between 
commands  6  and  7  and  the  D  drive  and  its  directories)  and  by  identifying 
changed  communication  linkages  (communication  between  commands  6'  and  7'  and 
the  E  drive  and  its  directories). 
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•  *♦*  Start. Bat  For  Token-Ring  User  Computer 

1  ECHO  OFF 

;  Establish  Path  to  Network  and  DOS  Programs  Residing  on  User  Computer 

2  PATH  C: \NETWDRK;C: \APrb\DOS 

:  *♦*  Establish  Access  tor  IDIR  Directory  Program  and  its  IDIRDATA 
:  Sub  Directory 

APPEND  C:\1DIRDATA 
ECHO  ON 

;  **•»  Load  Token-Ring  Programs 

3  TQKREUI 
NETBEUI 

■  Start  the  User  Computer  on  the  Network,  Using  Name  Provided  by 

:  User  (Replaceable  Parameter  7.i)  and  Speci-fy  Use  o-f  Resources 

:  (e.g.,  ASG  =  10  Devices  and  Directories) 

4  NET  START  MSG  7.1  /SRV:  1  /ASG:  10  /PB1:16K  /USN:3  /CMD:  12  /SES;  18 

:  ***  Request  Use  o-f  Server  Directories  on  Server  TN3  and  Printer  on  TN4: 
:  Application  Directory  APRS  (Virtual  Drive  E) ,  Application  Batch  Files 

:  DISKD  (Virtual  Drive  D)  and  Printer  PRINT 

5  NET  USE  E:  \\TN3\APPS 

NET  USE  D;  \\TN3\DISKD 

NET  USE  lPTI  \\TN4\PRINT 

;  ***  Access  D  Directory  which  Contains  IDIR  and  Application  Program 

:  Batch  Files 

6  D: 

***  Load  IDIR 

7  IDIR 


Incorrect 

Modi -f  i  cati  on :  Replace  commands  6  and  7  above  with  commands  6  and  7  : 
(comment  was  not  changed) 

;  ***  Access  D  Drive  which  Contains  IDIR  and  Program  Batch  Files 

6'  E: 

;  Load  Pro-file 

7'  PROFILE 


Correct 

Modi-f ication:  Replace  commands  6  and  7  above  with  commands  6'  and  7": 
(change  comment) 

:  ***  Access  E  Drive,  which  contains  PROFILE  program.  PROFILE  is  located 
:  on  the  Server.  PROFILE  processes  User  Computer  identification  in 

:  order  to  identify  the  User  Computer  hardware  configuration.  The 

:  execution  of  Profile  will  ultimately  lead  to  the  loading  of  IDIR 

:  and  access  to  application  batch  files. 

6'  E: 

:  **■»■  Load  Profile 

7'  PROFILE 


Figure  2.  Batch  file  for  Token-Ring  LAN  User  Computer  Start  Program 
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0  V  !  LOAD  START  FILE 


IDLE  ! - !  CAN'T  LOAD  START 

- I  i  FILE /ERROR  MSG. 

!  ! 

!  NE/LOAD  START  FILE  FROM  DOS  1 

1  V  V 

- !  CAN'T  LOCATE  ! - ! 

START  !  DIRECTORIES/ERRQR  MSG.  i  BACK  AT  I 

FILE  ! - >!  DOS  I 


LOADED 


ro 

<  --  " 

z 

m 

'EXECUTE  PATH  &  ! 

APPEND  COMMANDS  ! 

1 

1 

CAN'T  LOAD  TOKEN-RING 

PROGRAMS /ERROR  MSG.  ! 

DIRECTOR¬ 

IES 

LOCATED 

'LOAD  TOKEN-RING 

PROGRAMS 

CAN'T  START  NETWORK/ERROR  MSG. 

1  NE, 

3  V 

TOKEN- 

RING 

PROGRAMS 

LOADED 

I  NE/START  NETWORK 


4  V 


NETWORK 

STARTED 


RESOURCES  NOT 
AVAILABLE/ERROR  MSG. 


I  NE/REQUEST  RESOURCES 


5  V 


6  V 
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{DIRECTORY 
> ! PROGRAM 
i (IDIR) 

I  LOADED 


DRIVE  NOT  DEFINED/ERROR  MSG.  {  AT  NET! 
- >j  menu  ! 

^  '  I  — — — — — —  I  7 


NE/ACCESS  .  .  NE/LOAD  .  PROFILE  . 

DRIVE  E  .  DRIVE  E  .  PROFILE  .  PROGRAM  . 
- >.  ACCESSED. - >.  LOADED  . 


Figure  3.  State  Diagram  o-f  a  Token-Ring  LAN  User  Computer  Start  Progr 
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IV.  OBJECTIVE  OF  MAINTENANCE 

The  ob.iective  0+  maintenance  is  to  make  required  changes  in  software  in 
such  a  way  that  its  value  to  users  is  increased.  Required  changes  can  result 
■from  either  the  need  to  correct  errors  or  to  increase  the  -functionality  o-f  the 
so-f  tware. 

A.  Maintenance  Process 

In  the  broad  view  of  maintenance,  it  is  not  limited  to  making  post~del i very 
changes.  Rather,  it  is  a  process  that  starts  with  user  requirements  and  never 
ends  Even  the  installation  of  and  changes  to  a  replacement  system  can  be 

considered  part  of  the  maintenance  process.  Our  approach  to  identifying  the 
maintenance  functions  which  should  be  standardized  is  to:  1)  Adopt  the  view 
that  maintenance  is  a  process  of  change  management  and  2>  Identify  tasks  in 
maintenance  that  are  concerned  with  making  changes  to  software,  including 
changes  to  documentation  (e.g.,  specification,  design,  listing,  test  plan, 
etc .  )  . 

B.  Maintenance  Tasks 

Using  the  concept  of  change  management,  the  following  maintenance  tasks  can 
be  identified: 

o  Identify  need  for  change 

!  The  change  is  desired  to  prevent  users  from  accessing  resources  that  are 
not  available  to  them.  This  will  save  user  time  and  reduce  frustration,  i 

o  Determine  whether  change  should  be  made,  based  on  benefit-cost 
anal ysi s 

i  The  cost  is  approximately  one  man-day  maximum  to  code,  document  and  test  the 
change.  This  amounts  to  about  *  300  (with  employee  benefits).  This  is 
equivalent  to  about  100  users  saving  5  minutes  each,  assuming  salary  of  user 
(with  employee  benefits)  is  approximately  equal  to  implementer  salary,  on  the 
average.  The  break  even  point  could  be  achieved  within  two  weeks  of 
implementation,  given  the  number  of  users  and  uses  of  the  affected  application 
programs.  '• 

Evaluate  the  effects  of  change,  including  possible  side  effects 

o  Determine  whether  change  can  be  made  without  creating  an 
incompatibility  with  the  rest  of  the  software 

The  change  will  not  affect  user  logon  instructions.  Thus,  User. Bat,  which 
contains  logon  instructions,  will  not  be  affected.  A  change  will  be  required 
in  the  user  Autoexec. Bat  to  set  the  environment  (i.e.,  establish  the  user 
computer  configuration).  This  change  will  have  no  effect  on  the  user 
operation.  Changes  will  be  required  in  the  application  batch  files  (e.g., 
Smartcom. Bat )  that  are  stored  on  the  server  to  add  checks  of  the  configuration 
to  see  whether  the  user  has  the  resources  necessary  to  carry  out  the  attempted 
operation.  If  this  is  not  done  correctly,  there  will  be  errors  in  the 
operation  (e.g.,  the  user  will  be  allowed  to  attempt  an  operation  that  is  not 
possible  or  will  told  that  the  operation  is  not  possible  when,  in  fact,  it  is 
possible) .  I 


Fagel 3 


o  Make  the  change,  if  warranted,  and  only  if  it  can  be  done  in  a 
standard  way 

I  The  change  is  warranted  based  on  the  very  favorable  cost-benefit 
relationship.  The  change  can  be  made  in  a  standard  way  by  using  the  change 
management  methodology  that  fallows.  ! 

V.  METRICS  FOR  MAINTENANCE 

In  order  to  manage  software  change  it  is  desirable  to  measure  the  effects 
of  change.  This  is  accomplished  with  quality  metrics.  A  quality  metric  is 
defined  as  follows:  a  quantitative  measure  of  the  degree  to  which  software 
possesses  a  given  attribute  that  affects  its  quality  fl>.  Ideally,  there  would 
be  agreement  on  a  set  of  application-independent,  language-independent, 
software  structure-independent  metrics  (universal  metrics').  Agreement  does 
not  exist  in  the  software  engineering  community  on  a  universal  set.  Lacking 
this  agreement,  metrics  which  are  known  to  be  related  to  the  effectiveness  and 
efficiency  of  the  software  development  process  are  used  during  development  to 
measure  and  improve  the  development  process;  these  are  called  orocess  metrics 
f7>.  It  is  assumed  that  their  use  will  result  in  maintainable  software. 
However,  process  metrics,  like  traceability,  have  little  to  do  with  measuring 
whether  the  system  achieves  its  quality  requirements.  For  that  we  need  product 
metrics  like  rel  i  abi  1  i  ty',  accuracy,  response  time,  throughput,  etc.  The  two 
types  of  metrics  are  related  in  the  sense  that  high  process  metric  values  will 
contribute  to  high  product  metric  values.  Product  metrics  are  beyond  the  scope 
of  this  report . 

The  role  of  metrics  in  maintenance  can  be  demonstrated  by  posing  the 
fallowing  question; 

When  a  maintenance  action  is  taken,  how  are  the  releyant  metrics  values 
affected? 

o  What  are  the  relevant  metrics? 

!  Traceabi 1 i ty  I 

o  What  were  the  original  values? 

!  100  y.  between  code  and  state  diagram  ! 

o  What  are  the  new  values? 

1  <  100  ■/.  .  Can't  trace  from  Start. Bat  of  User  Computer  to  Server 
application  batch  files  1 
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o  Examine  incremental  changes 

!  Are  they  in  the  right  direction  (e.g.,  reduced  complexity)’’  < 

!  No.  Increased  complexity.  ! 

*  Are  they  approximately  the  right  values  (e.g.,  within  the  bounds  o-f 
experience  with  respect  to  the  maintenance  action)? 

!  Traceability  will  be  lost  i-f  the  change  is  extensive. 

The  change  should  not  involve  more  than  about  30  "/.  of  the 

batch  file.  If  this  is  not  the  case,  the  batch  file  should 

be  rewritten  (rule  of  thumb  regarding  percentage  of 
statements  changed) .  ! 

VI.  MODEL  OF  MAINTENANCE 

To  explain  the  dynamic  interaction  between  development  and  maintenance,  as 

exemplified  by  the  changes  in  metrics  values  that  result  from  development  and 

maintenance  actions,  the  model  in  Figure  4  is  provided.  A  model  of  the 
maintenance  process  is  essential  for  standardization  to  be  achieved.  Different 
organizations  may  want  to  use  different  metrics,  depending  on  the  relevance  of 
the  metrics  to  their  maintenance  environments  and  projects. 
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Development 

Methodology 


Af-fects  Ability 
to  Make  Correct 
Changes 


Contributes  ! 
to  Original  ) 
Metrics  Values  ! 


V  New  Metrics  v 

- !  Values  ! - 

Compute  Recompute! - >!  Maintenance 

Common  Metrics  1< - !  Actions 


Changes  Metricc 
Val ues 


V 

(Sample  List) 
Completeness 
Consistency 
M-'dul  ari  ty 
Traceabi 1 i tv 
Ver  1  -f  i  abi  1  i  ty 


V 

Add 

Del ete 
Modi-f  y 

Improved  I 

Maintainability"^  ! 


V  V 


Metrics  Data  Base 

1 

Maintenance  Data 

(Metrics  and 

—  > 

Correl ati on 

< — i 

Base  (Maintenance 

Projects  History) 

7 

Action  History) 

Figure  4.  Model  of  the  Interaction  between  Development,  Maintenance  and 
Metrics. 
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This  model  may  be  understood  and  applied  as  -follows: 

A.  Evaluate:  Estimate  the  incremental  change  in  metric  value  of  a  proposed 
maintenance  action.  If  the  software  change  is  made,  measure  its  effect  after 
the  change  is  made.  To  the  extent  feasible,  quantify  the  effect  of  the  change. 
The  following  questions  are  relevant  when  considering  a  change  to  software: 

o  Given  the  development  methodology  and  a  maintenance  action,  how  will  the 
metrics  values  be  affected  <magnitude  and  sign)?  Will  they  change  in  a 
direction  to  indicate  the  software  will  be  <ar  has  been)  improved?  Or  will  the 
change  indicate  that  the  software  will  be  <or  has  been)  degraded'!’ 

This  model  would  assist  the  maintenance  organization  to:  1>  determine 
whether  a  change  should  be  made,  2)  determine  whether  a  change  improved 
maintainability,  if  it  was  made,  and  3)  document  the  history  of  the  project 
and  the  change  so  that  this  information  can  be  used  when  making  future  change 
decisions. 

B.  Feedback:  Understand  that  taking  a  maintenance  action  changes  metrics 
values  and  that  the  new  metrics  values  will  influence  future  maintenance 
actions. 

C.  Data  bases;  Maintain  data  bases  of  project  charact er i st i cs ,  metrics,  and 
maintenance  actions  as  an  aid  to  learning  from  the  past:  Was  a  given  metric  a 
good  predictor  of  the  effect  of  a  given  maintenance  action?  Which  maintenance 
actions  improved  and  which  degraded  the  software  for  given  project 
character!  sti -cs?  Did  the  nature  of  the  development  methodology  influence  the 
maintainability  of  the  software"^ 

VII.  APPLICATION  OF  METRICS 

It  was  mentioned  previously  that  metrics  are  part  of  the  maintenance  model 
—  they  assist  in  evaluating  the  effects  of  change.  When  used  os-er  hundreds  of 
software  components  (an  element  of  a  software  system,  like  a  module),  the 
metrics  can  assume  numerical  values  (e.g.,  for  Compl eteness:  ratio  of 
completed  components  to  total  number  of  components  in  the  svstem) .  For  a 
single  component,  as  in  the  example,  a  qualitative  interpretation  is 
appropriate.  This  is  done  below  for  the  example,  using  typical  metrics. 
Although  the  modification  has  improved  functionality,  it  has  degraded 
maintainabi 1 ity . 
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TABLE  1 


METRICS  APPLIED  TO  EXAMPLE  PROGRAM 


Metri c 


Comp 1 eteness : 

Are  all  required 
software  components 
present? 

Consi stency : 

Are  the  code  and 
documentation 
uniform  and  free 
of  contradiction? 

Modul ar i ty : 

Is  the  structure 
coiiesive  and  seif- 
contai ned? 

Traceabi 1 i ty : 

Can  the  program 
parts  be  traced 
from  one  to 

another'!’ 

Ver i f i abi 1 i ty : 

Can  the  correct 
operation  and 
performance  of 
the  program  be 
ver i f i ed? 


Original 

Program 


Yes 


Yes 


No 


Yes 


Yes 


Modified  Program 


No.  The  correct  comment  is  missing. 


No.  The  comment  contradicts  the 
commands  and  vice  versa. 


No.  Quirks  of  the  DOS  language 
inhibit  modularity,  but  similar 
commands  are  grouped. 


No.  Can't  trace  between  commands, 
drives  and  directories. 


No.  The  erroneous  comment  confuses 
the  verification. 
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VIII.  STANDARDIZATION  OF  CHANGE  DOCUMENTATION 

Because  there  is  a  great  di-f-ference  in  applications,  programming 
environments,  etc. ,  in  various  organizations,  the  maintenance  standard  snould 
accommodate  those  differences  and  specify  only  a  minimum  set  of  requirements 
and  procedures. 

Standardization  can  be  viewed  as  a  process  of  posing  questions  prior  to  a 
maintenance  action  and  having  the  maintainer  answer  them.  The  purpose  of  this 
is  to  ensure  that  the  maintainer  has  thought  about  the  consequences  of 
proposed  changes  and  is  alerted  to  potential  pitfalls.  Maintenance  decisions 
and  actions  should  be  recorded  in  a  data  base  for  use  in  making  future 
maintenance  decisions. 

The  entities  which  are  subject  to  change  are  software  components.  For  the 
sake  of  brevity,  software  component'  will  hereafter  be  called  'component'. 

A.  Documenting  the  Effects  of  Change 

It  should  be  a  standard  procedure  of  maintenance  to  document  a  proposed 
change  in  the  following  format  (or  similar  format)  and,  if  the  change  is  made, 
to  fill  in  as  much  detail  as  possible  about  the  change.  The  items  to  be 
considered  in  deciding  on  a  change  are  more  important  than  the  specific  format 
used  to  document  the  change.  The  Xs  in  the  matrix  indicate  a  relationship 
between  an  input  item  and  an  output  item,  and  ' DNA '  means  'DOES  NOT  APPLY'. 

Change  an  input  (add  or  modify) 


Types  '  Batch  file  statements  ! 

Format  1  PC  DOS  batch  file  conventions  ! 

Value  (How  are  outliers  handled?  Are  they  used  or  rejected?)  1  DNA  1 
Range  (e.g.,  extremes  of  numbers):  !  DNA  I 
Precision  (e.g.,  number  of  decimal  points):  !  DNA  ! 

Accuracy  (e.g.,  number  within  X  '/.  of  actual  value):  I  DNA  ! 

Name  (Standardize  name;  should  say  what  component  does):  f  (Start) 
Starts  User  Computer  on  network  and  requests  resources  ! 
Questions: 

*  Mhat  is  the  effect  of  input  on  outputs? 

I  Link  between  Start. Bat  on  User  Computer  and  Server  application 
batch  files  I 

*  What  is  the  effect  of  input  on  computation  of  function? 

*  Computation  within  bounds?  (i.e. ,  does  input  cause  computation 
to  be  outside  feasible  range  of  numbers  in  application?):!  DNA  1 
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TABLE  2 

EXAMPLE  INPUT-OUTPUT  CHANGE  RELATIONSHIP 
OUTPUT  (Name) 


-)  T  ype 

INPUT 

(Name) 

Type  X 

Format 
Val  ue 
Range 
Preci si  on 
Accuracy 


Format  Value  Range  Precision 


X 


XXX 

XXX 

XXX 

XXX 


Accuracy 


X 

X 

X 

X 


I  Type;  New  statements  in  Start. Bat  on  User  Computer  creates  need  -for  new 
statements  in  application  batch  tiles,  i 


I  Format:  I-f  syntax  incorrect,  won't  wor^.  H  output  not  correctlv  related 
to  input,  could  make  wrong  decision  about  executing  apolication 
program.  ' 


Add/Modi  -f  Y 
statements 
(Need,  -for 


a  -function  or  statements;  What  resources,  -functions  or 
must  be  present  so  that  change  can  be  utilized? 
example,  paths,  directories,  and  disks  de-fined)  ! 
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B.  Documentation  Requirements 


As  a  minimum  the  following  should  be  standard  documentation  for  supporting 
maintenance;  requirements  specification,  design  speci f i cat i on ,  program 
listing,  test  plan,  and  test  results,  as  summarized  below. 


Phase 


Documentation 


i 


Requirements  Analysis  Requirements  Specification 

!  Need  environment  variables 
to  improve  useability  of 
LAN  and  to  simplify 
maintenance.  I 

Design  Speci f i cati on 

I  State  Diagram  1 

Li st i ng 

I  Batch  File  I 

Test  Plan,  Test  Results 

I  Test  use  of  application 
batch  files  from  all  User 
Computers. A1 1 ow  access  if 
configuration  permits  it; 
otherwise,  disallow  it.  1 

IX.  SOFTWARE  COMMUNICATION  MECHANISMS  AND  MAINTENANCE 

Mechanisms  which  are  available  for  communicating  between  components  are  an 
important  aspect  of  maintenance  because  of  the  serious  consequences  of  making 
an  error  in  adding  or  changing  a  linkage.  As  opposed  to  other  types  of 
software  changes,  a  change  in  a  communi cati on  mechanism  affects  more  than  one 
component.  This  is  particularly  important  for  networks  where  a  defective 
mechanism  can  adversely  affect  the  operation  of  computers  at  remote  sites. 

A.  Kinds  of  Communication  Mechanisms 

o  Data  linkages  (for  the  transfer  of  data): 

-  Message  passing  (can  also  be  control  message):  !  DNA  I 

-  Transaction  (e.g.,  update  in  a  data  base  management  system):  DNA 

-  Mail  Box  (i.e.,  store  data  in  standard  location  where  it  can  be  used 

by  other  processes) 

r 

!  Autoexec. Bat  on  User  Computer  stores  data  (its  ID)  in  standard 
location  (environment)  that  can  be  used  by  Profile. Bat  on 
Server  1 


)esi  qn 


Coding 


All 
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o  Control  linkages  (-for  the  trans-fer  o^  control) 

-  Subroutine  call:  )  DNA  I 

-  Procedure  cal  1 :  I  DNA  ! 

-  Remote  procedure  call  (RPC):  I  DNA  ! 

B.  Character  i  sti  cs  o-f  Communication  Between  So-ftware  Components 

1)  Expl i ci t : There  is  an  actual  transfer  or  exchange  of  data  or 

passing  of  parameters,  or  an  output  from  one  component 
is  the  input  to  another  component,  or  one  component  calls 
another  component. 

1  Start. Bat  on  User  Computer  calls  Profile. Bat  on  Server 

2)  I mpl i c i t : Based  on  the  oosition  of  the  given  component  within  a 

sequence  of  components  (e.g.,  instructions  in  a  pnocrao': 

I  Since  PROFILE  is  needed  to  determine  the  User  Ccmovst er 
configuration,  it  is  called  as  tn=  last  "’■-■vp  t  -  in 
Fiqu'^e  2.  I 

3)  I  ndi  r  ec  t !  B  ased  on  one  component  providinq  'e.n.  ,  sto^e  cats  -  ‘f’' 

or  secondarv'  storage*  that  another  component  u-es: 

Pro*  lie.  Bat  on  Server  sets  cont  i  nor  at  i  on  en  v  i  r  o'"  ’•en  t . 
Pppiication  batch  *ties  wi  !  !  '■e*srence  pne  en/i  '-on  men  t 

Be-^O'-e  -■-'mpcnents  :"-e  added,  nai^pod  o-  modi-^'ed,  it  snou’n  be  span: 
oroced  I'-e  ^  p  pccer’rai'"'  a  no  noc'-i’'5np  the  e^-ecps  of  mating  pna  cha'-.-e  on  i: 
component  "  omiT’i'n  i  p  a  1 1  r'n .  Fur  thermore .  it  the  cha'ge  is  made,  as  "'-■on  Petal! 
posainle  ='"0''!d  os  documented  aoout  the  cha-'s,  as  s'uqaested  bv'  the  cuesti 
tel  cw. 

4  ’  Ahn  a.  ;o'*ponent 

o  What  other  component'  will  the  giver  component  communicate  I'/ith 
once  it  added'’  !  component  ■=  batch,  tile  statement  ! 

I  Start . Bat  on  User  Computer  will  communicate  with  Prof  lie. Bat 
on  Serve'.  The  environment  will  communicate  with  applicati.on 
batch  files  on  Server  ! 

o  that  are  the  communication  linkages?  (parameter  passing,  message 
exchange,  RPC,  etc.?) 

Start. Bat  on  User  Computer  names  an  executable  batch  file  (e.g.. 
Profile)  and  causes  the  file  to  be  loaded  and  executed. 
Autoexec. Bat  sets  the  User  Computer  identification.  Profile. Bat 
on  Server  sets  the  configuration.  I 

o  What  existing  communication  linkages  will  be  affected  by  the 
change'i’:  !  None  ! 


:ard 
iter 
.  as 
L  ons 
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5)  DELETE  a  component  !  DNA  1 

o  What  communication  linkage  will  be  broken  bv  the  deletion"^ 

o  What  are  the  new  communication  linkages  that  result  -from  the 
del eti on? 

6)  MODIFY  a  component 

1  Modity  Start. Bat  and  application  batch  Tiles.  These  are  the 
components  to  be  modi  Tied.  ! 

o  What  is  the  existing  communication  linkage  which  involves  this 
component? 

1  None  between  Start. Bat  and  application  batch  Tiles  1 

o  How  will  this  communication  linkage  be  modiTied  bv  +:he  change  in 
the  component"^ 

I  A  communication  linkage  will  be  established  between  User 
Computer  and  Server  via  the  environment  I 


X.  STANDARDIZATION  THROUGH  EXAMINATION  OF  DEVELOPMENT  METHODOLOGIES 

There  is  evidence  that  the  characteristics  oT  development  methodologies  {0} 
and  the  characteristics  oT  programming  languages  <9}  can  inTluence 
maintainabilitv. 


A.  Character  1 st 1 cs  oT  Development  Methodology 

When  we  maintain  soTtware  we  may  not  be  cognizant  of  the  development 
methodology  which  was  used  to  produce  the  soTtware,  but  it  will  aTTect  our 
ability  to  maintain  the  soTtware.  The  evaluation  hinges  on  a  single  criterion; 
does  the  methodology  support  the  creation  o4  soTtware  which  is  easy  to  change 
without  inducing  side— eTTects  <an  unexpected  and  undesirable  result  oT  making 
a  change)?  This  objective  will  be  achieved  iT  the  methodology  Torces  the 
designer  to  Tormally  consider  the  consequences  oT  making  a  change  once  the 
soTtware  has  to  be  maintained  C10>.  It  Follows  that  in  order  to  capitalize  on 
a  methodology  that  supports  maintenance,  it  is  necessary  to  use  that 
methodology  to  maintain  the  soTtware.  The  Tollowing  is  a  standard  procedure 
Tor  evaluating  a  methodology  with  respect  to  its  capability  to  support 
mai ntenance. 
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Does  the  methodology  <e.g.,  state  diagram)  assist  to: 

1)  Identi+y  side-et tects  when  performing  maintenance 

I  The  state  diagram  (see  Figure  3)  can  assist  in 

identifying  potential  side-effects  because  it  shows:  changes 
of  state^^in  a  program,  events  that  cause  changes  in  state,  and 
;  resul  tailt^acti  ons.  For  example,  in  Figure  3  the  modified  state 
di agram  ^^|iows  a  transition  from  the  Resources  Assigned  state 
(step  5>  ^o  the  'Drive  E  Accessed state  (step  6')  that  could 
have  arv  effect  on  loading  the  directory  program  (step  7) 
because  the  modification  has  intervened  in  the  original 
program  e»<ecution  sequence.  We  could  have  a  problem  if  this 
intervention  prevents  the  directory  program  from  eventually 
being  loaded.  ! 

2)  Provide  ability  to  make  selective  change  (i.e.,  don't  change  or 
destroy  another  part  of  the  software  when  making  a  change) 

!  Obviously,  no  methodology  is  foolproof  in  identifying  the 
conseguences  of  making  a  change,  but  a  methodologv'  like  the 
state  diagram  forces  the  maintainer  to  consider  the  effects  of 
change  and  makes  visible  the  relationship  between  programs. 
For  example,  it  says  in  Figure  3  that  a  program  called 
PROFILE'  is  to  be  loaded.  This  raises  some  interesting 
questions  for  the  maintainer:  What  is  the  program  PROFILE";’ 
What  does  it  do?  Where  is  it  located?  The  incorrect 

modification  does  not  answer  these  questions.  The 
correct  modification  does.  However,  notice  that  the  state 
diagram  does  not  suggest  to  the  maintainer  that  the 

comments  are  incorrect;  only  the  listing  can  do  that.  This 
suggests  the  impossibility  of  higher  level  documentation 
providing  a  complete  description  of  program  logic.  I 

3)  Make  visible  the  dependencies  between  inputs,  processes  and 
outputs  (dependencies  make  it  difficult  to  change  the  software 
without  affecting  something  else  which  was  working  correctly 
prior  to  the  change) 

!  Dependencies  are  created  by  the  change  between  Start. Bat  and 
application  batch  files  and  between  Start. Bat  and  PROFILE. 
These  are  unavoidable,  given  the  approach  for  checking  User 
Computer  configuration.  However,  the  state  diagram  helps  to 
make  these  dependencies  visible.  They  would  be  more  visible 
to  the  reader  if  the  state  diagram  for  the  processing  of  the 
PROFILE  program  were  shown  (not  shown  because  it  is  beyond  the 
scope  of  this  report).  ! 

I 

4)  Determine  whether  change  can  be  made  without  creating  an 
incompatibility  with  the  rest  of  the  software 

^  I  This  would  be  determined  by  analyzing  the  application  batch 

files  and  state  diagrams  to  see  whether  an  incompatibility 
in  their  operation  would  be  created  by  checking  the  User 
Computer  configuration.  ! 
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5)  Support  a  rational  change  policy: 

o  Make  a  change,  if  warranted,  and  only  if  it  can  be  done  in  a 

standard  way,  a  'standard  way'  being  defined  as  being  in  ^-1 

conformance  with  the  above  procedure  for  assessing  the  impact 
of  change. 

i  To  assess  the  effect  of  the  change,  we  determine  how  the 
changed  Start. Bat  will  affect  the  application  batch  files. 

There  are  three  possibilities: 

-  They  will  no  longer  work  at  all 

-  They  will  deny  program  access  when  the  required  equipment 
is  available 

-  They  will  allow  program  access  when  the  required  equipment 
is  not  available 

-  They  will  work  satisfactorily  ! 

o  Make  changes  in  small,  controlled  increments 

!  By  breaking  the  logic  into  discrete  state  transitions  (e.g., 
transition  from  'RESOURCES  ASSIGNED'  (Step  5)  to  DRIVE  E 
ACCESSED  (Step  6)  in  Figure  3),  changes  are  kept  small. 

Also  the  individual  changes  are  kept  small  by  distributing 
parts  of  the  total  change  to  several  batch  files  (e.g.. 

Start. Bat,  Profile. Bat  and  application  batch  files!.  However, 
the  incorrect  modification  in  Figure  2  is  uncontrolled, 
raising  questions  about  the  function  and  location  of  PROFILE 
and  its  relationship  to  Start. Bat.  i 

B.  Characteristics  of  Programming  Language 

Characteristics  of  the  programming  language  can  also  significantly 
influence  the  ability  to  maintain  <95.  Two  brief  examples  from  the  DOS 
language  will  be  given: 

o  PATH  command:  If  this  command  appears  once  and  is  repeated,  the  most  recent 
occurrence  of  the  command  is  the  only  one  in  effect.  This  means  that  any  paths 
used  to  establish  directories  in  a  previous  occurrence  are  lost  unless  they 
are  repeated  in  the  new  PATH  command.  In  effect,  this  means  that  a  new  path 
must  be  a  superset  of  the  previous  path,  if  all  original  directory  information 
is  to  be  retained.  However,  this  could  result  in  long  path  commands  and, 
without  writing  complicated  logic,  commands  are  limited  to  a  single  line!  Thus 
the  maintenance  principle  of  being  able  to  make  a  selective  change  (i.e. ,  one  ^ 

wants  to  just  add  or  delete  parts  of  the  PATH  command,  not  write  a  new  one) 
cannot  be  achieved  with  this  command. 

r 
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o  IF  command:  The  IF  command  has  the  format:  IF  stringl==string2  command.  The 
reguirement  -for  the  second  '  =  '  is  unexpected.  This  nuance  of  the  language  has 
caused  us  to  make  several  errors  in  writing  network  batch  files.  This 
seemingly  minor  item  can  cause  havoc  in  maintenance  because  a  frequent  change 
to  batch  files  occurs  as  the  result  of  adding  capabilities  to  the  network  that 
are  conditioned  on  the  availability  of  certain  resources.  The  IF  command  is 
-J  key  to  specifying  these  conditions. 

X I .  SUMMARY 

We  have  proposed  that  maintenance  can  be  improved  through  standardization. 
The  elements  of  the  proposed  standardization  process  are  the  fallowing: 

o  Metrics 

o  Model  of  maintenance 
o  Change  documentat i on 
o  Software  communication  mechanisms 

o  Development  methodology  supportive  of  maintenance 

An  example  was  presented  of  the  application  of  one  development  methodology 
—  state  diagrams  —  to  illustrate  how  proposed  and  accomplished  changes  can 
be  illuminated  so  that  errors  can  be  avoided  and  maintainability  improved. 

Various  methodologies  could  have  been  used  to  illustrate  the  change 
management  methodology.  What  is  important  is  not  the  particular  development 
methodology,  but  the  consistent  application  of  a  selected  methodologv,  using 
the  change  management  methodology  which  has  been  described.  Additional 
research  is  needed  to  test  other  types  of  applications,  programming  languages 
and  changes  against  the  change  management  methodology. 
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